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Security Implications of Predictable Fragment Identification Values 
Abstract 


IPv6 specifies the Fragment Header, which is employed for the 
fragmentation and reassembly mechanisms. The Fragment Header 
contains an "Identification" field that, together with the IPv6 
Source Address and the IPv6 Destination Address of a packet, 
identifies fragments that correspond to the same original datagram, 
such that they can be reassembled together by the receiving host. 

The only requirement for setting the Identification field is that the 
corresponding value must be different than that employed for any 
other fragmented datagram sent recently with the same Source Address 
and Destination Address. Some implementations use a simple global 
counter for setting the Identification field, thus leading to 
predictable Identification values. This document analyzes the 
security implications of predictable Identification values, and 
provides implementation guidance for setting the Identification field 
of the Fragment Header, such that the aforementioned security 
implications are mitigated. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7739. 


Gont Informational [Page 1] 


RFC 7739 Implications of Predictable Fragment IDs February 2016 


Copyright Notice 


Copyright (c) 2016 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


Table of Contents 


1. Introduction 3 
2. Terminology... : 3 
3. Security Impiicatiónė Sa Predictable. Pragnent Identification 
Values .. Iah 3 
4. Constraints för the Seléction of Fragment Identification 
Values sete or 7 
5. Algorithms fór. Selecting. Fragment fdeńti fication ‘Values s ip 8 
5.1. Per-Destination Counter (Initialized to a Random Value) 8 
5.2. Randomized Identification Values . . a 9 
5.3. Hash-Based Fragment Identification Selection Algorithm = -I0 
6. “Security Considerations- e e ea a ta e a e a e a we ea ey E2 
7. References .. goan fer ibe Gen a e EE a auan aa Gp ae Ps e r Gas. ES 
7.1. Normative Rarer ences Sects Bei A. cay he RM cee ct Ae ecg: LS 
7.2. Informative References .. ew een te ce kA 
Appendix A. Information Leakage Produced by ‘Yuinerabie 
Implementations . . awin Ga pg ap “ARG 
Appendix B. Survey of Fragment Tdentification. Selection 
Algorithms Employed by Popular IPv6 Implementations 18 
Aeknöwledgements ssc ane ES e ENE Se wy Gree e a a e Ce a e oe a i 2o 
RÜUtROE So AddArESSi Tyme, wi Tae SY a As A e a ae a we gy Ss a aen a a WP ee, T a “ZO 


Gont Informational [Page 2] 


RFC 7739 Implications of Predictable Fragment IDs February 2016 


Les 


Introduction 


IPv6 specifies the Fragment Header, which is employed for the 
fragmentation and reassembly mechanisms. The Fragment Header 
contains an "Identification" field that, together with the IPv6 
Source Address and the IPv6 Destination Address of a packet, 
identifies fragments that correspond to the same original datagram, 
such that they can be reassembled together by the receiving host. 

The only requirement for setting the Identification field is that its 
value must be different than that employed for any other fragmented 
datagram sent recently with the same Source Address and Destination 
Address. 


The most trivial algorithm to avoid reusing Identification values too 
quickly is to maintain a global counter that is incremented for each 
fragmented datagram that is transmitted. However, this trivial 
algorithm leads to predictable Identification values that can be 
leveraged to perform a variety of attacks. 


Section 3 of this document analyzes the security implications of 
predictable Identification values. Section 4 discusses constraints 
in the possible algorithms for selecting Identification values. 
Section 5 specifies a number of algorithms that could be used for 
generating Identification values that mitigate the issues discussed 
in this document. Finally, Appendix B contains a survey of the 
algorithms employed by popular IPv6 implementations for generating 
the Identification values. 


Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 
Security Implications of Predictable Fragment Identification Values 
Predictable Identification values result in an information leakage 
that can be exploited in a number of ways. Among others, they may 


potentially be exploited to: 


o determine the packet rate at which a given system is transmitting 
information 


o perform stealth port scans to a third party 
o uncover the rules of a number of firewalls 


o count the number of systems behind a middle-box 
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o perform Denial-of-Service (DoS) attacks, or 


o perform data injection attacks against transport or application 
protocols 


The security implications introduced by predictable Identification 
values in IPv6 are very similar to those of predictable 
Identification values in IPv4. 


NOTE: 
[Sanfilippol998a] originally pointed out how the IPv4 
Identification field could be examined to determine the packet 
rate at which a given system is transmitting information. Later, 
[Sanfilippol998b] described how a system with such an 
implementation could be used to perform a stealth port scan to a 
third (victim) host. [Sanfilippol999] explained how to exploit 
this implementation strategy to uncover the rules of a number of 
firewalls. [Bellovin2002] explained how the IPv4 Identification 
field could be exploited to count the number of systems behind a 
NAT. [Fyodor2004] is an entire paper on most (if not all) the 
ways to exploit the information provided by the Identification 
field of the IPv4 header (and these results apply in a similar way 
to IPv6). [Zalewski2003] originally envisioned the exploitation 
of IP fragmentation/reassembly for performing data injection 
attacks against upper-layer protocols. [Herzberg2013] explores 
the use of IPv4/IPv6 fragmentation and predictable Identification 
values for performing DNS cache poisoning attacks in great detail. 
[RFC6274] covers the security implications of the IPv4 case in 
detail. 


One key difference between the IPv4 case and the IPv6 case is that, 
in IPv4, the Identification field is part of the fixed IPv4 header 
(and thus usually set for all packets), while in IPv6 the 
Identification field is present only in those packets that carry a 
Fragment Header. As a result, successful exploitation of the 
Identification field depends on two different factors: 


o vulnerable Identification generators, and 


o the ability of an attacker to trigger the use of IPv6 
fragmentation for packets sent from/to the victim node 


The scenarios in which an attacker may successfully perform the 
aforementioned attacks depend on the specific attack type. For 
example, in order to perform a DoS attack on communications between 
two hosts, an attacker would need to know the IPv6 addresses employed 
by the aforementioned two nodes. Such knowledge may be readily 
available if the target of the attack is the communication between 
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two specific BGP peers, two specific SMTP servers, or one specific 
primary DNS server and one of its secondary DNS servers, but may not 
be easily available if the goal is a DoS attack on all communications 
between arbitrary IPv6 hosts (e.g., the goal is to perform a DoS 
attack on all communications involving one specific node with 
arbitrary/unknown hosts). Other attacks, such as performing stealth 
port scans to a third party or determining the packet rate at which a 
given system is transmitting information, only require the attacker 
to know the IPv6 address of a vulnerable implementation. 


As noted in Section 1, some implementations have been known to use 
predictable Identification values. For instance, Appendix B of this 
document shows that recent versions of a number of popular IPv6 
implementations employ predictable values for the Identification 
field of the Fragment Header. 


Additionally, we note that [RFC2460] states that when an ICMPv6 
Packet Too Big (PTB) error message advertising a Maximum Transfer 
Unit (MTU) smaller than 1280 bytes is received, the receiving host is 
not required to reduce the Path-MTU for the corresponding Destination 
Address, but must simply include a Fragment Header in all subsequent 
packets sent to that destination. This triggers the use of the so- 
called IPv6 "atomic fragments" [RFC6946]: IPv6 fragments with a 
Fragment Offset equal to 0, and the "M" ("More fragments") bit clear. 
[DEPGEN] documents the motivation of deprecating the generation of 
IPv6 atomic fragments in [RFC2460]. 


Thus, an attacker can usually cause a victim host to "fragment" its 
outgoing packets by sending it a forged ICMPv6 Packet Too Big (PTB) 
error message that advertises an MTU smaller than 1280 bytes. 


There are a number of aspects that should be considered, though: 


o All the implementations the author is aware of record the Path-MTU 
information on a per-destination basis. Thus, an attacker can 
only cause the victim to enable fragmentation for those packets 
sent to the Source Address of IPv6 packet embedded in the payload 
of the ICMPv6 PTB message. However, we note that Section 5.2 of 
[RFC1981] notes that an implementation could maintain a single 
system-wide Path MTU (PMTU) value to be used for all packets sent 
to that node. Clearly, such implementations would exacerbate the 
problem of any attacks based on Path MTU Discovery (PMTUD) 
[RFC5927] or IPv6 fragmentation. 


o If the victim node implements some of the counter-measures for 
ICMP attacks described in RFC 5927 [RFC5927], it might be 
difficult for an attacker to cause the victim node to employ 
fragmentation for its outgoing packets. However, many current 
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implementations fail to enforce these validation checks. For 
example, Linux 2.6.38-8 does not even require received ICMPv6 
error messages to correspond to an ongoing communication instance. 


o Some implementations (notably Linux) have already been updated 
according to [DEPGEN] such that ICMPv6 PTB messages do not result 
in the generation of IPv6 atomic fragments. 


Implementations that employ predictable Identification values and 
also fail to enforce validation checks on ICMPv6 error messages 
become vulnerable to the same type of attacks that can be exploited 
with IPv4 fragmentation, discussed earlier in this section. 


One possible way in which predictable Identification values could be 
leveraged for performing a DoS attack is as follows: Let us assume 
that Host A is communicating with Host B, and that an attacker wants 
to perform a DoS attack such communication. The attacker would learn 
the Identification value currently in use by Host A, possibly by 
sending any packet that would elicit a fragmented response (e.g., an 
ICPMv6 echo request with a large payload). The attacker would then 
send a forged ICMPv6 PTB error message to Host A (with the IPv6 
Source Address of the embedded IPv6 packet set to the IPv6 address of 
Host A, and the Destination Address of the embedded IPv6 packet set 
to the IPv6 address of a Host B), such that any subsequent packets 
sent by Host A to Host B include a Fragment Header. Finally, the 
attacker would send forged IPv6 fragments to Host B, with their IPv6 
Source Address set to that of Host A, and Identification values that 
would result in collisions with the Identification values employed 
for the legitimate traffic sent by Host A to Host B. If Host B 
discards fragments that result in collisions of Identification values 
(e.g., such fragments overlap, and the host implements [RFC5722]), 
the attacker could simply trash the Identification space by sending 
multiple forged fragments with different Identification values, such 
that any subsequent packets from Host A to Host B are discarded at 
Host B as a result of the malicious fragments sent by the attacker. 


NOTE: 
For example, Linux 2.6.38-10 is vulnerable to the aforementioned 
issue. 


[RFC6946] describes an improved processing of these packets that 
would eliminate this specific attack vector, at least in the case 
of TCP connections that employ the Path-MTU Discovery mechanism. 


The aforementioned attack scenario is simply included to illustrate 


the problem of employing predictable Identification values. We note 
that regardless of the attacker’s ability to cause a victim host to 
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employ fragmentation when communicating with third parties, use of 
predictable Identification values makes communication flows that 
employ fragmentation vulnerable to any fragmentation-based attacks. 


4. Constraints for the Selection of Fragment Identification Values 


The Identification field of the Fragment Header is 32-bits long. 
However, when translators (e.g. [RFC6145]) are employed, the high- 
order 16 bits of the Identification field are effectively ignored. 


NOTE: 
[RFC6145] notes that, when translating in the IPv6-to-IPv4 
direction, "if there is a Fragment Header in the IPv6 packet, the 
last 16 bits of its value MUST be used for the IPv4 identification 
value". 


Additionally, Section 3.3 of [RFC6052] encourages operators to use 
a Network-Specific Prefix (NSP) that maps the IPv4 address space 
into IPv6. Thus, when an NSP is being used, IPv6 addresses 
representing IPv4 nodes (reached through a stateless translator) 
are indistinguishable from native IPv6 addresses. 


Thus, when translators are employed, the "effective" length of the 
Identification field is 16 bits and, as a result, at least during the 
IPv6/IPv4 transition/co-existence phase, it is probably safer to 
assume that only the low-order 16 bits of the Identification field 
are of use to the destination system. 


Regarding the selection of Identification values, the only 
requirement specified in [RFC2460] is that the Identification value 
must be different than that of any other fragmented packet sent 
recently with the same Source Address and Destination Address. 
Failure to comply with this requirement could lead to the 
interoperability problems discussed in [RFC4963]. 


From a security standpoint, unpredictable Identification values are 
desirable. However, this is somewhat at odds with the "reuse" 
requirements specified in [RFC2460], that specifies that an 
Identification value must be different than that employed for any 
other fragmented packet sent recently with the same Source Address 
and Destination Address. 


Finally, since Identification values need to be selected for each 
outgoing datagram that requires fragmentation, the performance impact 
should be considered when choosing an algorithm for the selection of 
Identification values. 
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3% 


Algorithms for Selecting Fragment Identification Values 


There are a number of algorithms that may be used for setting the 
Identification field such that the security issues discussed in this 
document are avoided. This section presents three of those. 


The algorithm in Section 5.1 typically leads to a low Identification 
reuse frequency at the expense of keeping per-destination state; this 
algorithm only uses a Pseudorandom Number Generator (PNRG) when the 
host communicates with a new destination. The algorithm in 

Section 5.2 may result in a higher Identification reuse frequency. 
It also uses a PRNG for each datagram that needs to be fragmented. 
Hence, the algorithm in Section 5.1 will likely result in better 
performance properties. Finally, the algorithm in Section 5.3 
achieves a similar Identification reuse frequency to that of the 
algorithm in Section 5.1 without the need of keeping state, but 
possibly at the expense of lower per-packet performance. 


NOTE: 
Since the specific algorithm to be employed for the PRNGs in 
Section 5.1 and Section 5.2, and the specific algorithms to be 
employed for the hash functions in Section 5.3 have not been 
specified, it is impossible to provide a quantitative performance 
comparison of the algorithms described in this section. 


Per-Destination Counter (Initialized to a Random Value) 
This algorithm consists of the following steps: 


1. Whenever a packet must be sent with a Fragment Header, the 
sending host should look up in the Destination Cache an entry 
corresponding to the Destination Address of the packet. 


2. If such an entry exists, it contains the last Identification 
value used for that Destination Address. Therefore, such a value 
should be incremented by 1 and used for setting the 
Identification field of the outgoing packet. Additionally, the 
updated value should be recorded in the corresponding entry of 
the Destination Cache [RFC4861]. 


3. If such an entry does not exist, it should be created, and the 
Identification value for that destination should be initialized 
with a random value (e.g., with a Pseudorandom Number Generator), 
and used for setting the Identification field of the Fragment 
Header of the outgoing fragmented datagram. 
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The advantages of this algorithm are: 


o It is simple to implement, with the only complexity residing in 
the PRNG used to initialize the Identification value contained in 
each entry of the Destination Cache. 


o The Identification reuse frequency will typically be lower than 
that achieved by a global counter (when sending traffic to 
multiple destinations), since this algorithm uses per-destination 
counters (rather than a single system-wide counter). 


o It has good performance properties (once the corresponding entry 
in the Destination Cache has been created and initialized, each 
subsequent Identification value simply involves the increment of a 
counter). 


The possible drawbacks of this algorithm are: 


o If, as a result of resource management, an entry of the 
Destination Cache must be removed, the last Identification value 
used for that Destination will be lost. Thus, subsequent traffic 
to that destination would cause that entry to be recreated and 
reinitialized to random value, thus possibly leading to 
Identification "collisions". 


o Since the Identification values are predictable by the destination 
host, a vulnerable host might possibly leak to third parties the 
Identification values used by other hosts to send traffic to it 
(i.e., Host B could leak to Host C the Identification values that 
Host A is using to send packets to Host B). Appendix A describes 
one possible scenario for such leakage in detail. 


5.2. Randomized Identification Values 


Clearly, use of a Pseudorandom Number Generator for selecting the 
Identification would be desirable from a security standpoint. With 
such a scheme, the Identification of each fragmented datagram would 
be selected as: 


Identification = random() 
where "random()" is the PRNG. 
The specific properties of such scheme would clearly depend on the 
specific PRNG employed. For example, some PRNGs may result in higher 
Identification reuse frequencies than others, in the same way that 


some PRNGs may be more expensive (in terms of processing requirements 
and/or implementation complexity) than others. 
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Discussion of the properties of possible PRNGs is considered out of 


the scope of this document. However, we do note that some PRNGs 
employed in the past by some implementations have been found to be 
predictable [Klein2007]. Please see [RFC4086] for randomness 


requirements for security. 

5.3. Hash-Based Fragment Identification Selection Algorithm 
Another alternative is to implement a hash-based algorithm similar to 
that specified in [RFC6056] for the selection of transport port 
numbers. With such a scheme, the Identification value of each 


fragmented datagram would be selected with the expression: 


Identification = F(Sre IP, Dst IP, secretl) + 
counter[G(Sre IP, Dst Pref, secret2) ] 


where: 


Identification: 
Identification value to be used for the fragmented datagram. 


F(): 
Hash function. 

Sre IP: 
IPv6 Source Address of the datagram to be fragmented. 

Dst IP: 
IPv6 Destination Address of the datagram to be fragmented. 

secretl: 
Secret data unknown to the attacker. This value can be 
initialized to a pseudo-random value during the system 
bootstrapping sequence. It should remain constant at least while 
there could be previously sent fragments still in the network or 
at the fragment reassembly buffer of the corresponding destination 
system(s). 

counter[]: 
System-wide array of 32-bit counters (e.g. with 8K elements or 
more). Each counter should be initialized to a pseudo-random 
value during the system bootstrapping sequence. 

G(): 


Hash function. It may or may not be the same hash function as 
that used for F(). 
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Dst Pref: 
IPv6 "Destination Prefix" of the datagram to be fragmented (can be 
assumed to be the first eight bytes of the Destination Address of 
such packet). Note: the "Destination Prefix" (rather than 
Destination Address) is used, such that the ability of an attacker 
of searching the "increments" space by using multiple addresses of 
the same subnet is reduced. 


secret2: 
Secret data unknown to the attacker. This value can be 
initialized to a pseudo-random value during the system 
bootstrapping sequence. It should remain constant at least while 
there could be previously sent fragments still in the network or 
at the fragment reassembly buffer of the corresponding destination 
system(s). 


NOTE: 
counter[G(srce IP, Dst Pref, secret2)] should be incremented by one 
each time an Identification value is selected. 


The output of F() will be constant for each (Src IP, Dst IP) pair. 
Similarly, the output of G() will be constant for each (Src IP, Dst 
Pref) pair. Thus, the resulting Identification value will be the 
result of a random offset plus a linear function (provided by 
counter[]), therefore resulting in a monotonically increasing 
sequence of Identification values for each (src IP, Dst IP) pair. 


NOTE: 
F() essentially provides the unpredictability (by off-path 
attackers) of the resulting Identification values, while counter[] 
provides a linear function such that the Identification values are 
different for each fragmented packet while the Identification 
reuse frequency is minimized. 


The advantages of this algorithm are: 


o The Identification reuse frequency will typically be lower than 
that achieved by a global counter (when sending traffic to 
multiple destinations), since this algorithm uses multiple system- 
wide counters (rather than a single system-wide counter). The 
extent to which the reuse frequency will be lower depends on the 
number of elements in counter[], and the number of other active 


flows that result in the same value of G() (and hence cause the 
same counter to be incremented for each datagram that is 
fragmented). 
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o It is possible to implement the algorithm such that good 
performance is achieved. For example, the result of F() could be 
stored in the Destination Cache (such that it need not be 
recomputed for each packet that must be sent) along with the 
computed index/argument for counter[]. 


NOTE: 
If this implementation approach is followed, and an entry of 
the Destination Cache must be removed as a result of resource 
management, the last Identification value used for that 
Destination will *not* be lost. This is an improvement over 
the algorithm specified in Section 5.1. 


The possible drawbacks of this algorithm are: 


o Since the Identification values are predictable by the destination 
host, a vulnerable host could possibly leak to third parties the 
Identification values used by other hosts to send traffic to it 
(i.e., Host B could leak to Host C the Identification values that 
Host A is using to send packets to Host B). Appendix A describes 
a possible scenario in which that information leakage could take 
place. We note, however, that this algorithm makes the 
aforementioned attack less reliable for the attacker, since each 
counter could be possibly shared by multiple traffic flows (i.e., 
packets destined to other destinations might cause the same 
counter to be incremented). 


This algorithm might be preferable (over the one specified in 
Section 5.1) in those scenarios in which a node is expected to 
communicate with a large number of destinations, and thus it is 
desirable to limit the amount of information to be maintained in 
memory. 


NOTE: 
In such scenarios, if the algorithm specified in Section 5.1 were 
implemented, entries from the Destination Cache might need to be 
pruned frequently, thus increasing the risk of Identification 
"collisions". 


6. Security Considerations 
This document discusses the security implications of predictable 


Identification values, and provides implementation guidance such that 
the aforementioned security implications can be mitigated. 
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A number of possible algorithms are described, to provide some 
implementation alternatives to implementers. We note that the 
selection of such an algorithm usually implies a number of trade-offs 
(security, performance, implementation complexity, interoperability 
properties, etc.). 
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Appendix A. Information Leakage Produced by Vulnerable Implementations 


Section 3 provides a number of references describing a number of ways 
in which a vulnerable implementation may reveal the Identification 
values to be used in subsequent packets, thus opening the door to a 
number of attacks. In all of those scenarios, a vulnerable 
implementation leaks/reveals its own Identification number. 


This section presents a different attack scenario, in which a 
vulnerable implementation leaks/reveals the Identification number of 
a non-vulnerable implementation. That is, a vulnerable 
implementation (Host A) leaks the current Identification value in use 
by a third-party host (Host B) to send fragmented datagrams from Host 
B to Host A. 


NOTE: 
For the most part, this section is included to illustrate how a 
vulnerable implementation might be leveraged to leak out the 
Identification value of an otherwise non-vulnerable 
implementation. 


The following scenarios assume: 


Host A: 
An IPv6 host that implements the algorithm specified in 
Section 5.1, implements [RFC5722], but does not implement 
[RFC6946]. 


Host B: 
Victim node. Selects the Identification values from a global 
counter. 


Host C: 
Attacker. Can forge the IPv6 Source Address of his packets at 
will. 


In the following scenarios, large ICMPv6 Echo Request packets are 
employed to "sample" the Identification value of a host. We note 
that while the figures show only one packet for the ICMPv6 Echo 
Request and the ICMPv6 Echo Reply packets, each of those packets will 
typically comprise two fragments, such that the corresponding 
unfragmented datagram is larger than the MTU of the networks to which 
Host B and Host C are attached. Additionally, the following 
scenarios assume that Host A employs a Fragment Header when sending 
traffic to Host B (typically the so-called "IPv6 atomic fragments" 
[RFC6946]): this behavior may be triggered by forged ICMPv6 PTB 
messages that advertise an MTU smaller than 1280 bytes (assuming the 
victim still generates atomic fragments [DEPGEN]). 
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In lines #1-#2 (and lines #7-#8), the attacker samples the current 
Identification value at Host B. In line #3, the attacker sends a 
forged TCP SYN segment to Host A. In line 4, the attacker sends a 
forged TCP segment to Host B as an incomplete IPv6é fragmented 
datagram (e.g., a single fragment with Fragment Offset=0, More 
fragments=1). If corresponding TCP port is closed, and the attacker 
fails when trying to produce a collision of Identification values 
(see line #4), the following packet exchange might take place: 


A B C 
#1 <------ Echo Req #1 ----------- 
#2 --- Echo Repl #1, FID=5000 ---> 
#300 <---------- 7-7-7777 SYN #1, src= B ----------------------- 
#4 <--- SYN/ACK, FID=42 src=A ---- 
#5 ---- SYN/ACK, FID=9000 ---> 
#6 <----- RST, FID= 5001 ----- 
#7 <-------- Echo Req #2 --------- 
#8 --- Echo Repl #2, FID=5002 ---> 


The RST segment in line #6 is elicited by the SYN/ACK segment from 
line #5 (illegitimately elicited by the SYN segment from line #3). 
The packet from line #4, sent as an incomplete IPv6 datagram, 
eventually times out. 


On the other hand, if the attacker succeeds to produce a collision of 
Identification values, the following packet exchange could take 


place: 

A B C 
#1 <------- Echo Req #1 ---------- 
#2 -—-- Echo Repl #1, FID=5000 ---> 
#300 <------------------- SYN #1, src= B --~---~--~--------------- 
#4 <-- SYN/ACK, FID=9000 src=A --- 
#5 ---- SYN/ACK, FID=9000 ---> 

(RFC5722) 

#6 <------- Echo Req #2 ---------- 
#7 ---- Echo Repl #2, FID=5001 --> 


Clearly, the Identification value sampled from the second ICMPv6 Echo 
Reply packet ("Echo Repl #2") implicitly indicates whether the 
Identification value in the forged SYN/ACK (see line #4 in both 
figures) was the current Identification value in use by Host A. 


As a result, the attacker could employ this technique to learn the 


current Identification value used by host A to send packets to host 
B, even when Host A itself has a non-vulnerable implementation. 
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Appendix B. 


Implications of Predictable Fragment IDs 


Survey of Fragment Identification Selection Algorithms 


Employed by Popular IPv6 Implementations 


This section includes a survey of the Identification selection 
algorithms employed by some popular operating systems. 


NOTE: 


February 2016 


The survey was produced with the SI6 Networks’ IPv6 toolkit 
[SI6-IPv6]. 
tesa aoe SSeS SSS assess Sas Sesse = ten ee Se a oa oe ae + 
Operating System | Algorithm 
aa aa ean rl aa a a am Se ee ee + 
Cisco IOS 15.3 | Predictable (Global Counter, 
| Init=0, Incr=1) 
e sn + 
FreeBSD 9.0 | Unpredictable (Random) 
hese ge Sao Saas See Se Se eae Pease SSS aaa apa a aoa ee ae Se eee T= + 
Linux 3.0.0-15 | Predictable (Global Counter, 
| Init=0, Incr=1) 
eE SS TS ee E TEA Se O A E + 
Linux-current Unpredictable (Per-dest Counter, 
Init=random, Incr=1) 
ba Se ai a SS Se ee + 
NetBSD 5.1 | Unpredictable (Random) 
bee Sages Se see aoc sar oso oes oe sesame conc aS ue scm lens in mon oe came + 
OpenBSD-current | Unpredictable (Random, SKIP32) 
satan ar ar te toa nla enon mo an am iS + 
Solaris 10 | Predictable (Per-dst Counter, 
| Init=0, Incr=1) 
toscane a n e N E + 
Windows XP SP2 | Predictable (Global Counter, 
| Init=0, Incr=2) 

T A EA AE tre Sey a ee R ee + 
Windows XP Professional | Predictable (Global Counter, 
32bit, SP3 | Init=0, Incr=2) 

PSS Sa Sas an h ho SS Sas ees ee See ee See + 

Windows Vista (Build 6000) | Predictable (Global Counter, 
| Init=0, Incr=2) 
peh e ieee pore ti e + 
Windows Vista Business | Predictable (Global Counter, 
64bit, SP1 | Init=0, Incr=2) 
por Sea ee ee ee tre SSS SSeS a ere ee + 
Windows 7 Home Premium | Predictable (Global Counter, 
| Init=0, Incr=2) 
PESS SSS SSSse SSeS e Pee SS SS tess sss oso Ss SSS = SSS SH= + 
Windows Server 2003 R2 | Predictable (Global Counter, 
Standard 64bit, SP2 | Init=0, Incr=2) 
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e A E A A a a + 
| Windows Server 2008 Standard | Predictable (Global Counter, | 
| 32bit, SP1 | Init=0, Incr=2) | 
E E A E N tas E EET TS N + 
| Windows Server 2008 R2 | Predictable (Global Counter, | 
| Standard 64bit, SP1 | Init=0, Incr=2) | 
r A S tas A E T E + 
| Windows Server 2012 Standard | Predictable (Global Counter, | 
| 64bit | Init=0, Incr=2) | 
P a A a E A A O a a a + 
| Windows 7 Home Premium | Predictable (Global Counter, | 
| 32bit, SP1 | Init=0, Incr=2) | 
toa = tans A r a + 
| Windows 7 Ultimate 32bit, | Predictable (Global Counter, 

| SP1 | Init=0, Incr=2) | 
hese Se aS SS eae SSS tee e so aa see aa See er enna eae + 
| Windows 8 Enterprise 32 bit | Unpredictable (Alg. from Section | 
| | 5.3) | 
E AEAT T E r A AE ETE AA A TA A EA O EIE + 


Table 1: Fragment Identification algorithms employed by different OSs 


NOTE: 
In the text above, "predictable" should be taken as "easily 
guessable by an off-path attacker, by sending a few probe 
packets". 
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